REMARKS 

The specification has been amended to correct a typographical error. Claims 1, 11, 12, 
14, 22, 23, 25, 33, 34, and 36 have been amended to clarify the invention. Claims 1-4, 6-15, 17- 
26, and 28-39 remain pending. 

The Examiner rejected claims 1-4, 6-15, 17-26, and 28-39 under 35 U.S.C. § 103(a) as 
being unpatentable over Crump et al. (U.S. 6,892,245) in view of Gelb (U.S. 5,550,984) further 
in view of Aysan et al. (U.S. 2003/0108041). The Examiner's rejections are respectfully 
traversed as follows. 

Claim 1 is directed towards a "method for performing network address translation on 
data." Claim 1 also recites "receiving a first data having a first source address and a first 
destination address, wherein the first data is sent by a first node in a first domain to a second 
node in a second domain, and wherein the first data is received into a first interface associated 
with the first domain and output from a second interface associated with the second domain, and 
wherein the first domain differs from the second domain." Claim 1 also recites "wherein the first 
and second interfaces are virtual interfaces that are each configurably associated with one or 
more domains." Claim 1 also recites "if the first source address is a private address and if a 
binding between the first source address, the first interface, and a first public address is not 
found, translating the first source address into a selected public address and forming and storing 
a first binding between the first source address, the selected public address, and the first 
interface ." That is, if a binding between a public address, private address and virtual interface 
of the received data is not found , such a binding is formed . Claim 1 further requires "if the first 
source address is a private address and if a binding between the first source address, the first 
interface, and a first public address is found , translating the first source address into the first 
public address specified by the found binding prior to sending the first data to the second domain 
destination." Once this binding between a private address, public address, and virtual interface 
is formed, it is then used to perform NAT translation based on a public address, private address, 
and a virtual interface that is associated with the received data. The remaining independent 
claims include mechanisms for performing the same operations as claim 1. 

Basing NAT operations on a virtual interface has several associated advantages. For 
instance, a virtual interface can flexibly be associated with any number of interfaces and 
corresponding domains. One example of this arrangement is shown in Figure 7, which illustrates 
a plurality of interfaces associated with each NAT virtual interface (or NVI). Other advantages 
are described below and specified with respect to claims 11 and 12, among other places. 
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The primary reference Crump fails to teach or suggest mechanisms for forming and using 
a binding between a private address, a public address and a virtual interface , in the manner 
claimed. Although Crump appears to perform a NAT operation based on a mapping to a domain 
identifier of the destination domain (see Col. 9, Lines 9-15 and Col. 10, Lines 42-46), Crump 
does not appear to teach or suggest performing a NAT operation based on a mapping to a virtual 
interface , in the manner claimed. Crump does not have any teachings or enablement regarding 
virtual interfaces. A description of such a technique for utilizing NAT virtual interfaces as it 
pertains to one embodiment of the claimed invention is provided on page 19, line 16 of the 
specification and Figure 7. As described and illustrated, each NAT virtual interface may be 
configurably associated with one or more interfaces and associated one or more networks by 
forming or dismantling differently configured NAT virtual interfaces. However, Crump fails to 
teach, suggest, or enable NAT operations based on a binding between a local address, public 
address, and a virtual interface, in the manner claimed. 

It is also respectfully submitted that the secondary references have the same deficiencies. 
The secondary reference Gelb is cited as disclosing forming a binding between a private address, 
an interface, and a public address. However, the cited portions of Gelb merely refer generally to 
"software used to bind a network interface adapter (22) to the Internet or other private network. 
See Col. 5, Lines 28-30 (Emphasis added). At most, this binding is between an interface and a 
single network, rather than between a virtual interface , a private address, and a public address, in 
the manner claimed. This binding software is described as providing an address that allows a 
public user to find and attach to the front end of the security system. Supra Lines 31-32. This 
cited passage fails to teach or suggest forming a binding between a virtual interface, a private 
address, and a public address and use of such binding, in the manner claimed. 

The secondary reference Aysan is cited as teaching a technique for translating an address 
based on a binding between an interface, a private address, and a public address of a particular 
node. Aysan appears to teach using interface addresses for routing purposes, rather than for 
performing translation of source or destination addresses. Aysan also fails to teach or suggest 
forming or using a binding between a virtual interface, a private address, and a public address, in 
the manner claimed. In the portions cited by the Examiner, Aysan starts by teaching a mapping 
between a private and public address (as defined in an ARP table) that are shared with routers in 
a particular VPN, and various components of this VPN are described. See paragraph [0042]. 
Specifically, Aysan teaches a network interface 310, that receives a packet from a particular 
source having a private address (see paragraph [0045]), then "proceeds to look up (step 806) the 
private destination address 714 (10.20.1.1) in a routing table to learn that the packet should be 
sent to the remove CVR tunnel interface 412, which ...has an address of 10.1.2.1." See 
paragraph [0046]. Aysan notes that the ARP table also associates the addresses of particular 
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interfaces, such as BR tunnel interface 314A and local CVR tunnel interface 312. See paragraph 
[0048]. The received packet is encapsulated with the addresses of the routing interfaces. See 
paragraph [0049]. The source address (or any other address) of the packet is not translated based 
on a binding between a virtual interface , a private address, and a public address, in the manner 
claimed. Additionally, Aysan fails to teach forming such a binding between a virtual interface , a 
private address, and a public address, in the manner claimed. 

Accordingly, it is respectfully submitted that independent claims 1, 14, 25, and 36 are 
patentable over the cited references. 

The Examiner's rejections of the dependent claims are also respectfully traversed. 
However, to expedite prosecution, all of these claims will not be argued separately. Claims 2-4, 
6-13, 15, 17-24, 26, 28-35, and 37-39 each depend directly or indirectly from independent claims 
1, 14, 25, or 36 and, therefore, are respectfully submitted to be patentable over cited art for at 
least the reasons set forth above with respect to claims 1, 14, 25, or 36. Further, the dependent 
claims require additional elements that when considered in context of the claimed inventions 
further patentably distinguish the invention from the cited art. 

For example, claim 11 recites "wherein each virtual interface defines which interfaces 
may communicate with which other interfaces." In a further aspect, claim 12 recites "wherein 
each virtual interface defines which interfaces can communicate with which other interfaces by 
specifying interface as belonging to one or more groups so that a particular interface is specified 
as being allowed to communicate with another interface if the particular interface and other 
interface belong to a same group." All of the cited references appear to be silent with respect to 
the use of virtual interfaces so as to specify which interfaces can communicate with each other, 
in the manner claimed. 
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Applicant believes that all pending claims are allowable and respectfully requests a 
Notice of Allowance for this application from the Examiner. Should the Examiner believe that a 
telephone conference would expedite the prosecution of this application, the undersigned can be 
reached at the telephone number set out below. 

Respectfully submitted, 
BEYER WEAVER, LLP 

/Mary R. Olynick/ 

Mary R. Olynick 
Reg. 42,963 

P.O. Box 70250 
Oakland, CA 94612-0250 
(510) 663-1100 
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